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Stateless Source Address Mapping for ICMPv6 Packets 
Abstract 


A stateless IPv4/IPv6 translator may receive ICMPv6 packets 


containing non-IPv4-translatable addresses as the source. These 
packets should be passed across the translator as ICMP packets 
directed to the IPv4 destination. This document presents 


recommendations for source address translation in ICMPv6 headers to 
handle such cases. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6791. 
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publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Table of Contents 


Li, 


bh 


Introduction ews is 

Notational Conventions WA ee te 

Problem Statement and Considerations 

.1. Considerations 

3.2. Recommendations 
ICMP Extension ee GE eign des fone: Del 
Stateless Address Mapping Algorithm 
Security Considerations 
Acknowledgments 

. References aS te at Sete 

8.1. Normative References 

8.2. Informative References 


WN 
w 


(oo aa ss 
annr PP BWW WWD 


Introduction 


Section 5.3 of "IP/ICMP Translation Algorithm" [RFC6145] states that 
"the IPv6 addresses in the IPv6 header may not be IPv4-translatable 
addresses and there will be no corresponding IPv4 addresses 
representing this IPv6é address. In this case, the translator can do 
stateful translation. A mechanism by which the translator can 
instead do stateless translation of this address is left for future 
work." This document, "Stateless Source Address Mapping for ICMPv6 
Packets", provides recommendations for this case. 


For the purposes of this document, the term "IPv4-translatable IPv6 
address" is as defined in Section 2.2 of [RFC6052]. 
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Notational Conventions 


The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 
document, are to be interpreted as described in [RFC2119]. 


Problem Statement and Considerations 


When a stateless IPv4/IPv6 translator receives an ICMPv6 message 
[RFC4443] (for example, "Packet Too Big") sourced from a non-IPv4- 
translatable IPv6é address and bound for an IPv4-translatable IPv6 
address, the translator needs to pick a source address with which to 
generate an ICMP message. For the reasons discussed below, this 
choice is problematic. 


Considerations 


The source address used SHOULD NOT cause the ICMP packet to be 
discarded. It SHOULD NOT be drawn from [RFC1918] or [RFC6598] 
address space, because that address space is likely to be subject to 
unicast Reverse Path Forwarding (uRPF) [RFC3704] filtering. 


IPv4/IPv6 translation is intended for use in contexts where IPv4 
addresses may not be readily available. Therefore, it is not 
considered appropriate to assign IPv4-translatable IPv6 addresses for 
all internal points in the IPv6 network that may originate ICMPv6 
messages. 


Another consideration for source selection is that it should be 
possible for the IPv4 recipients of the ICMP message to be able to 
distinguish between different IPv6 network origination of ICMPv6 
messages (for example, to support a traceroute diagnostic utility 
that provides some limited network-level visibility across the IPv4/ 
IPv6 translator). This consideration implies that an IPv4/IPv6 
translator needs to have a pool of IPv4 addresses for mapping the 
source address of ICMPv6 packets generated from different origins, or 
to include the IPv6 source address information for mapping the source 
address by others means. Currently, the TRACEROUTE and MTR [MTR] are 
the only consumers of translated ICMPv6 messages that care about the 
ICMPv6 source address. 


Recommendations 
The recommended approach to source selection is to use a single (or 
small pool of) public IPv4 address as the source address of the 


translated ICMP message and leverage the ICMP extension [RFC5837] to 
include the IPv6 address as an Interface IP Address Sub-Object. 
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ICMP Extension 


In the case of either a single public IPv4 address (the IPv4 
interface address or loopback address of the translator) or a pool of 
public IPv4 addresses, the translator SHOULD implement the ICMP 
extension defined by [RFC5837]. The ICMP message SHOULD include the 
Interface IP Address Sub-Object and specify the source IPv6 addresses 
of the original ICMPv6. When an enhanced traceroute application is 
used, it can derive the real IPv6 source addresses that generated the 
ICMPv6 messages. Therefore, it would be able improve on visibility 
towards the origin rather than simply blackholing at or beyond the 
translator. In the future, a new ICMP extension whose presence 
indicates that the packet has been translated and that the source 
address belongs to the translator, not the originating node, can also 
be considered. 


Stateless Address Mapping Algorithm 


If a pool of public IPv4 addresses is configured on the translator, 
it is RECOMMENDED to randomly select the IPv4 source address from the 
pool. Random selection reduces the probability that two ICMP 
messages elicited by the same TRACEROUTE might specify the same 
source address and, therefore, erroneously present the appearance of 
a routing loop. 


[RFC5837] extensions and an enhanced traceroute application, if used, 
will reveal the IPv6 source addresses that generated the original 
ICMPv6 messages. 


Security Considerations 


This document recommends the generation of IPv4 ICMP messages from 
IPv6 ICMP messages. These messages would otherwise have been 
discarded. New considerations are not expected to result from this 
change. As with a number of ICMP messages, a spoofed source address 
may result in replies arriving at hosts that did not expect them 
using the facility of the translator. 
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